home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc1608.txt < prev    next >
Text File  |  1994-08-01  |  40KB  |  1,124 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       T. Johannsen
  8. Request for Comments: 1608                            Dresden University
  9. Category: Experimental                                      G. Mansfield
  10.                                                   AIC Systems Laboratory
  11.                                                               M. Kosters
  12.                                                   Network Solutions,Inc.
  13.                                                              S. Sataluri
  14.                                                   AT&T Bell Laboratories
  15.                                                               March 1994
  16.  
  17.  
  18.            Representing IP Information in the X.500 Directory
  19.  
  20. Status of this Memo
  21.  
  22.    This memo defines an Experimental Protocol for the Internet
  23.    community.  This memo does not specify an Internet standard of any
  24.    kind.  Discussion and suggestions for improvement are requested.
  25.    Distribution of this memo is unlimited.
  26.  
  27. Abstract
  28.  
  29.    This document describes the objects necessary to include information
  30.    about IP networks and IP numbers in the X.500 Directory. It extends
  31.    the work "Charting networks in the X.500 Directory" [1] where a
  32.    general framework is presented for representing networks in the
  33.    Directory by applying it to IP networks.  This application of the
  34.    Directory is intended to support the work of IP network assigning
  35.    authorities, NICs, as well as other applications looking for a
  36.    mapping of IP numbers to data of related networks. Furthermore,
  37.    Autonomous Systems and related routing policy information can be
  38.    represented in the Directory along with their relationship to
  39.    networks and organizations.
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Johannsen, Mansfield, Kosters & Sataluri                        [Page 1]
  59.  
  60. RFC 1608         IP Information in the X.500 Directory        March 1994
  61.  
  62.  
  63. Table of Contents
  64.  
  65.       1. Introduction                                     2
  66.       2. IP images of networks                            3
  67.       2.1 IP network image                                3
  68.       2.2 IP node image                                   5
  69.       2.3 IP network interface image                      6
  70.       2.4 Autonomous Systems                              7
  71.       3. Number assignment information                    7
  72.       3.1 Delegated Block object                          8
  73.       3.2 IP Group object                                 9
  74.       3.3 IP Reference object                            10
  75.       3.4 AS Block object                                10
  76.       3.5 AS Reference object                            10
  77.       4. Directory tree                                  11
  78.       4.1 IP image objects                               11
  79.       4.2 AS objects                                     11
  80.       4.3 Namespace objects                              11
  81.       4.4 Relationship to organizational entries         13
  82.       5. Security Considerations                         14
  83.       6. Authors' Addresses                              15
  84.       References                                         16
  85.       Appendix: OID tables                               17
  86.  
  87. 1. Introduction
  88.  
  89.    Information related to the Internet Network Infrastructure is created
  90.    and stored by a number of different organizations, such as the
  91.    Internet Assigned Numbers Authority (IANA), Internet Registry (IR),
  92.    Network Information Centers (NICs), and the NSFNET Network Operations
  93.    Center (NOC).  This information is generally "mastered" (stored and
  94.    maintained) by these organizations on a centralized basis, i.e.,
  95.    there is a single place to look for a definitive list of entries for
  96.    these categories.  This has worked well in the past but given the
  97.    tremendous growth of the Internet and its number of users and
  98.    networks, it is essential that a distributed schema be used.
  99.  
  100.    The X.500 Directory offers the appropriate technology for
  101.    implementing this distributed method of managing network
  102.    infrastructure information.
  103.  
  104.    The following goals are addressed in this document:
  105.  
  106.     o Provision of IP specific images of network elements
  107.     o Mapping from Network Number to network, owner, provider etc.
  108.     o Support of delegation of IP address blocks
  109.     o Storage of high-level routing policies and AS information
  110.     o Support of "classless" network address formats
  111.  
  112.  
  113.  
  114. Johannsen, Mansfield, Kosters & Sataluri                        [Page 2]
  115.  
  116. RFC 1608         IP Information in the X.500 Directory        March 1994
  117.  
  118.  
  119.     o Provision of several organizational images of a network
  120.  
  121.    It may be noted that the document basically consists of two parts.
  122.    In the first part, an IP specific extension of the general framework
  123.    "Charting networks in the Directory" [1] is given.  Objects defined
  124.    by the application of this framework are related to IP numbers. An IP
  125.    namespace is defined in the second part of this paper, referring to
  126.    IP network elements defined at the beginning.
  127.  
  128. 2. IP images of networks
  129.  
  130.    As defined in [1], networks are modeled as a set of subnetworks and
  131.    nodes, called network elements in the remainder. To obtain a
  132.    particular view of a network element, images were introduced.  Below,
  133.    images of network elements for an IP specific view are defined.
  134.    Please note that images contain references to underlying physical
  135.    information about elements.
  136.  
  137.    In the remainder, ipStringSyntax is used as attribute type for all
  138.    attributes that are to hold an IP number. Currently, there are two
  139.    definitions for a syntax like this:
  140.  
  141.     o IpAddress as of [5]
  142.     o ip as of [6]
  143.  
  144.    It is suggested to use CaseIgnoreStringSyntax for implementations for
  145.    the time being with the convention to use the ordinary IP syntax.
  146.    Nevertheless, an OID has been reserved for ipStringSyntax (see
  147.    Appendix).
  148.  
  149. 2.1 IP network image
  150.  
  151.    IP network image is one application of network images and therefore
  152.    inherits the networkImageClass. This class is given below for
  153.    reference only, its definition can be found in [1].
  154.  
  155.    networkImage OBJECT CLASS
  156.     SUBCLASS of ImageCommunicationObject
  157.     MAY CONTAIN
  158.      externalGateway :: distinguishedNameSyntax,
  159.       /* points to one or more nodes that act
  160.          as gateway for the protocol application
  161.          this image refers to */
  162.  
  163.    An IP network combines all network elements that have a common IP
  164.    network number.  Presently, IP network numbers fall into one of the
  165.    classes A, B, or C. However, sub- and supernetworking is already done
  166.    broadly, and classless networks numbers are expected to be assigned
  167.  
  168.  
  169.  
  170. Johannsen, Mansfield, Kosters & Sataluri                        [Page 3]
  171.  
  172. RFC 1608         IP Information in the X.500 Directory        March 1994
  173.  
  174.  
  175.    soon. [2] proposes to assign bitwise contiguous blocks of class-C-
  176.    addresses to all networks with more than 255 nodes. The definition of
  177.    IP network, therefore, is always related to common network number and
  178.    network mask.
  179.  
  180.    IP networks have a very close relationship to the Domain Name System.
  181.    Several attributes are introduced to take care of these relations.
  182.    Though we do not intend to abolish the existing DNS service, the
  183.    schema defined here is able to provide the mapping IP number to
  184.    domain name and vice versa.
  185.  
  186.    An IP network image object as defined below is intended to provide
  187.    technical and administrative data for one IP network. Attributes hold
  188.    information that a NIC-WHOIS server would reveal for the network, and
  189.    more.
  190.  
  191.    ipNetworkImage OBJECT CLASS
  192.     SUBCLASS of NetworkImage
  193.     MUST CONTAIN
  194.      ipNetworkImageName :: CaseIgnoreString,
  195.       /* common name */
  196.      ipNwNumber :: IPStringSyntax,
  197.       /* the IP network number for
  198.          this (sub)network */
  199.      ipNwMask :: IPStringSyntax
  200.       /* mask that applies to ipNwNumber
  201.          in order to define classless
  202.          network number; also used for routing */
  203.  
  204.     MAY CONTAIN
  205.     /* DNS related info ; e.g. - */
  206.      associatedDomain :: CaseIgnoreStringSyntax,
  207.       /* the domain name associated to this IP network;
  208.          As there is not always a 1:1 mapping between traditional
  209.          IP numbers and domain names, the name given here
  210.          should contain the "closest match".
  211.          1) (sub)network does not have a domain name
  212.             of its own, but is part of a bigger domain:
  213.             take name of that domain
  214.          2) network is divided into several domains,
  215.             therefore having more than one domain name:
  216.             list all of them.
  217.          Note: a reverse mapping of domain names to
  218.          networks/nodes can be achieved by a modified
  219.          implementation of RFC1279 */
  220.      inAddrServer :: DistinguishedNameSyntax,
  221.       /* refers to the ipNodeImageObject of the
  222.          inaddr Server that holds information about
  223.  
  224.  
  225.  
  226. Johannsen, Mansfield, Kosters & Sataluri                        [Page 4]
  227.  
  228. RFC 1608         IP Information in the X.500 Directory        March 1994
  229.  
  230.  
  231.          this network */
  232.     /* routing policy; e.g. - */
  233.      asNumber :: integerStringSyntax,
  234.       /* number of Autonomous System this network belongs to */
  235.      acceptedUsagePolicy :: caseIgnoreStringSyntax,
  236.       /* semantics to be defined */
  237.     /* Any other - */
  238.      provider   :: DistinguishedNameSyntax,
  239.       /* points to network provider */
  240.      onlineDate :: uTCTimeSyntax
  241.       /* date when network got connected to the Internet */
  242.  
  243. 2.2 IP node image
  244.  
  245.    If a node in the network is running the IP protocol, an
  246.    ipNodeImageObject should be created for this node. This image is a
  247.    subclass of nodeImageClass and holds IP specific information.  The
  248.    nodeImageClass is given below for reference only, its definition can
  249.    be found in [1].
  250.  
  251.    nodeImage OBJECT CLASS
  252.     SUBCLASS of ImageCommunicationObject
  253.      /* no attributes common for all nodeImages have been
  254.         defined yet */
  255.  
  256.    An ipNodeImage is used to obtain technical and administrative
  257.    information on a host. The object is defined as follows:
  258.  
  259.    ipNodeImage OBJECT CLASS
  260.     SUBCLASS of NodeImage
  261.     MUST CONTAIN
  262.      ipNodeName :: CaseIgnoreString
  263.       /* common name, it is advised to use
  264.          the hostname for this purpose */
  265.     MAY CONTAIN
  266.      protocol :: CaseIgnoreString,
  267.       /* name and version of IP protocol running */
  268.      domainName :: CaseIgnoreString,
  269.       /* the complete domain name of this node;
  270.          CNAMEs can be stored additionally to the
  271.          DNS A record name;
  272.          further relationships, like MX record entries,
  273.          should be taken care of by the domain name tree
  274.          according to RFC 1279 */
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Johannsen, Mansfield, Kosters & Sataluri                        [Page 5]
  283.  
  284. RFC 1608         IP Information in the X.500 Directory        March 1994
  285.  
  286.  
  287. 2.3 IP network interface image
  288.  
  289.    The most important IP related information of a node (its IP
  290.    addresses) is registered with ipNetworkInterfaceImageObjects.  This
  291.    picture is accurate as a node can have several IP addresses, but at
  292.    most one per interface.  Furthermore, it shows clearly the
  293.    relationship between interface and neighboring IP network.
  294.  
  295.    IpNetworkInterfaceImage is a subclass of networkInterfaceImageClass.
  296.    The networkInterfaceImageClass is given below for reference only, its
  297.    definition can be found in [1].  Note that for
  298.    ipNetworkInterfaceImage all references are drawn in the context of
  299.    IP, i.e., networkInterfaceAddress becomes an IP address and
  300.    connectedNetwork points to an ipNetworkImageObject.
  301.  
  302.    networkInterfaceImage OBJECT CLASS
  303.     SUBCLASS of ImageCommunicationObject
  304.     MAY CONTAIN
  305.      networkInterfaceAddress     :: caseIgnoreStringSyntax,
  306.       /* this interface's address in the context the
  307.          image refers to, e.g. IP number, NSAP */
  308.      connectedNetwork   :: distinguishedNameSyntax
  309.       /* pointer to networkImageObject that describes
  310.          the network this interface is attached to in terms
  311.          of the protocol or application the images
  312.          indicates */
  313.  
  314.    Additionally, ipNetworkInterfaceImageObject has the following
  315.    properties:
  316.  
  317.    ipNetworkInterfaceImage OBJECT CLASS
  318.     SUBCLASS of NetworkInterfaceImage
  319.     MUST CONTAIN
  320.      ipNetworkInterfaceName :: CaseIgnoreStringSyntax
  321.       /* It is suggested that the interface name
  322.          is derived from the name of the logical
  323.          device this interface represents for the
  324.          operating system, e.g. le0, COM1 */
  325.     MAY CONTAIN
  326.      ipNwMask ::  IPStringSyntax
  327.       /* mask that applies to networkInterfaceAddress for
  328.          routing of packets to nodes on the connected
  329.          (broadcast) network;
  330.          Note: This is only a fraction
  331.          of the routing table information
  332.          for this interface, namely for one hop. */
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Johannsen, Mansfield, Kosters & Sataluri                        [Page 6]
  339.  
  340. RFC 1608         IP Information in the X.500 Directory        March 1994
  341.  
  342.  
  343. 2.4 Autonomous Systems
  344.  
  345.    Autonomous Systems (AS) are defined in asObject which is a subclass of
  346.    imageCommunicationObject.  It provides technical and administrative
  347.    information of an AS. Furthermore, routing policies can be stored with
  348.    the AS object.  The definition of the AS object is aligned with the
  349.    corresponding database object defined in [3].
  350.  
  351.    as OBJECT CLASS
  352.     SUBCLASS of  ImageCommunicationObject
  353.     MUST CONTAIN
  354.      asNumber :: IntegerStringSyntax
  355.  
  356.     MAY CONTAIN
  357.      asName :: CaseIgnoreStringSyntax,
  358.       /* if there is a name different from AS */
  359.      asIn ::  CaseIgnoreStringSyntax,
  360.       /* accepted routes from other AS */
  361.       /* for syntax and semantics refer [3] */
  362.      asOut :: CaseIgnoreStringSyntax,
  363.       /* generated routes announced to others */
  364.       /* for syntax and semantics refer [3] */
  365.      asDefault ::CaseIgnoreStringSyntax,
  366.       /* how default routing is handled */
  367.       /* for syntax and semantics refer [3] */
  368.      asGuardian :: DistinguishedNameSyntax, */
  369.       /* DN of guardian of this AS */
  370.      lastModifiedDate :: UTCtimeSyntax */
  371.       /* important as routes change frequently */
  372.  
  373.    Note that routing policies for an Autonomous System are represented
  374.    by the {asIn, asOut} attributes of asObject. Due to performance
  375.    constraints of present X.500 technology, it will probably not be used
  376.    directly by routers for dynamic routing.  However, it certainly can
  377.    be used in network management systems to determine the allowed paths
  378.    [i.e.,  in accordance with published policies] between two networks.
  379.    This will be useful in finding alternate paths, and evaluating the
  380.    connectivity of networks.
  381.  
  382. 3. Number assignment information
  383.  
  384.    In the following, Directory objects have been defined to represent IP
  385.    and AS (Autonomous System) namespace in the Directory. Their purpose
  386.    is to provide
  387.  
  388.      o mapping from IP number to IP network element (network or node)
  389.      o mapping from IP number to AS number and vice versa
  390.      o assignment and delegation information
  391.  
  392.  
  393.  
  394. Johannsen, Mansfield, Kosters & Sataluri                        [Page 7]
  395.  
  396. RFC 1608         IP Information in the X.500 Directory        March 1994
  397.  
  398.  
  399.    The need for a global, distributed database supporting the objectives
  400.    arises mainly from distributed IP- and AS-number assignment.
  401.  
  402.    Describing all IP numbers with one of the new objects delegatedBlock,
  403.    ipGroup and ipReference leads to the desired information. AS number
  404.    information is stored with the objects asBlock and asReference.
  405.    Furthermore, all assigned numbers have some properties in common.
  406.    Therefore, an objectclass assignedNumberClass is introduced. This
  407.    class exports attributes to delegatedBlock, ipGroup, ipReference,
  408.    asBlock, and asReference.
  409.  
  410.    AssignedNumberClass is defined as follows ("number" always refers to
  411.    IP number of delegatedBlock, network, host, and AS number, resp.):
  412.  
  413.    assignedNumberClass OBJECT CLASS
  414.     SUBCLASS of  top
  415.     MAY CONTAIN
  416.      assBy :: DistinguishedNameSyntax,
  417.       /* refers to an organization or organizationalRole
  418.          that assigned the number to assTo (see below) */
  419.      assTo :: DistinguishedNameSyntax,
  420.       /* refers to organization or organizationalRole
  421.          that the number was assigned to. This does not
  422.          imply that assTo "owns" this number now. */
  423.      assDate :: uTCTimeSyntax,
  424.       /* date of assignment for this number */
  425.      nicHandle :: CaseIgnoreStringSyntax,
  426.       /* gives the unique ID for a description
  427.          related to this number.
  428.          format: "handle : nic-domain-name"
  429.          example: MAK21 : rs.internic.net */
  430.      relNwElement ::  DistinguishedNameSyntax,
  431.       /* the network element related to this number
  432.          (network or node) */
  433.  
  434. 3.1 Delegated Block object
  435.  
  436.    This object provides information on a block of IP addresses delegated
  437.    to some local-authority or service provider. Only contiguous blocks
  438.    can be represented with the following schema. If an organization
  439.    (say, a NIC) has been assigned several IP network numbers which do
  440.    not form a contiguous block, it might want to use a different form of
  441.    representing that fact (e.g., using imageNetworks).  The
  442.    delegatedBlock object holds lower and upper bounds of the block.
  443.  
  444.    Note that the above does not make any assumption about the network
  445.    masks being constrained by byte boundaries. We can thus represent
  446.    subnetting within a "network (number)" that often happens within an
  447.  
  448.  
  449.  
  450. Johannsen, Mansfield, Kosters & Sataluri                        [Page 8]
  451.  
  452. RFC 1608         IP Information in the X.500 Directory        March 1994
  453.  
  454.  
  455.    organization in the same framework.
  456.  
  457.    This schema does lead to some granularity in the otherwise flat IP-
  458.    number space. Further, the granularity is significant as it may be
  459.    used to identify the administrator of the block - a service provider
  460.    or a domain manager.  E.g., it fits well into the schema of
  461.    aggregating networks for routing purposes as has been proposed in
  462.    [4].
  463.  
  464.    The object delegatedBlock is of the form:
  465.  
  466.    delegatedBlock OBJECT CLASS
  467.     SUBCLASS of AssignedNumberClass
  468.     MUST CONTAIN
  469.      delegatedBlockName :: caseIgnoreStringSyntax,
  470.      lowerBound :: IPStringSyntax,
  471.       /* smallest IP address belonging to the
  472.          block, e.g. 195.100.0.0 */
  473.      upperBound :: IPStringSyntax
  474.       /* highest  IP address belonging to the
  475.          block, e.g. 195.103.255.255 */
  476.  
  477.    The attribute relNwElement (inherited from AssignedNumberClass) can
  478.    point to a networkImage covering all networks within the block if
  479.    this makes sense.
  480.  
  481. 3.2 IP Group object
  482.  
  483.    This object provides information for an IP network number.  Its
  484.    purpose is basically only to
  485.  
  486.       o show that the number has been assigned, and
  487.       o provide a reference to the descriptive ipNetworkObject for
  488.         this network.
  489.  
  490.    Regardless of the actual value of x, IP group objects may exist for
  491.    IP numbers x.0.0.0, x.y.0.0 and x.y.z.0. This approach includes
  492.    "classical" class-A, -B and -C network addresses as well as any kind
  493.    of super- and subnetworking.
  494.  
  495.    The IP group object is a subclass of assignedNumberClass. The
  496.    attribute relNwElement points to an ipNetworkImage as defined above.
  497.  
  498.    ipGroup OBJECT CLASS
  499.     SUBCLASS of  AssignedNumberClass
  500.     MUST CONTAIN
  501.      ipGroupName :: IPStringSyntax,
  502.       /* IP number; x.0.0.0 or x.y.0.0 or x.y.z.0
  503.  
  504.  
  505.  
  506. Johannsen, Mansfield, Kosters & Sataluri                        [Page 9]
  507.  
  508. RFC 1608         IP Information in the X.500 Directory        March 1994
  509.  
  510.  
  511.          where x, y, z in 1..255 */
  512.      ipNwMask   ::    IPStringSyntax
  513.       /* mask that applies to all numbers
  514.          within the group; used to define
  515.          classless networking;  */
  516.  
  517. 3.3 IP Reference object
  518.  
  519.    There is one IP reference object for each IP host address.  The
  520.    purpose of this object is to
  521.  
  522.      o tell that this IP number is already assigned to a node
  523.      o give a pointer to the related ipNodeImageObject
  524.  
  525.    The IP reference object is a subclass of assignedNumberClass.  The
  526.    attribute relNwElement points to an ipNodeImage.
  527.  
  528.    ipReference OBJECT CLASS
  529.     SUBCLASS of  AssignedNumberClass
  530.     MUST CONTAIN
  531.      ipReferenceName :: IPString
  532.       /* value is always IP address */
  533.  
  534. 3.4 AS block object
  535.  
  536.    The AS block object is used to show delegation of blocks of AS
  537.    numbers to regional registries. This is similar to delegatedBlock of
  538.    ipNetwork numbers.
  539.  
  540.    asBlock OBJECT CLASS
  541.     SUBCLASS of  AssignedNumberClass
  542.     MUST CONTAIN
  543.      asBlockName :: caseIgnoreStringSyntax,
  544.      asLowerBound :: integerStringSyntax,
  545.      asUpperBound :: integerStringSyntax
  546.  
  547.    An AS block will comprise several consecutive AS numbers.  Objects to
  548.    describe these numbers may be stored in asObjects.
  549.  
  550. 3.5 AS reference object
  551.  
  552.    An AS reference object is used to show that an Autonomous System
  553.    number has been assigned (and thus can not be given to somebody
  554.    else).  Similar to ipGroup, asReference does not contain technical
  555.    details about an autonomous system itself but rather points (with
  556.    relNwElement) to a descriptive asObject.
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Johannsen, Mansfield, Kosters & Sataluri                       [Page 10]
  563.  
  564. RFC 1608         IP Information in the X.500 Directory        March 1994
  565.  
  566.  
  567.    asReference OBJECT CLASS
  568.     SUBCLASS of  AssignedNumberClass
  569.     MUST CONTAIN
  570.      asNumber :: integerStringSyntax
  571.  
  572. 4. Directory tree
  573.  
  574.  
  575.                               root
  576.                                |
  577.                  +-------------+---------------+
  578.                  |                             |
  579.                 c=                         o=Internet
  580.                  |                             |
  581.            +-----+------+               +------+-------+
  582.            |            |               |              |
  583.           ipNw=       as=             dbl=           asB=
  584.            |                            |              |
  585.           ipNd=                       ipG=           asRef=
  586.            |                            |
  587.           ipNwIf=                     ipRef=
  588.  
  589.               Figure 1: Overall relationship of objects.
  590.  
  591. 4.1 IP image objects
  592.  
  593.    According to [1], IP image entries will be stored underneath the
  594.    organization / organizationalUnit entry of the entity responsible for
  595.    that network. The case that such an entry does not yet exist in the
  596.    white-pages pilot is discussed in 4.4 below.
  597.  
  598. 4.2 AS objects
  599.  
  600.    The technical and administrative description of an AS is basically
  601.    maintained by NICs, network providers, or other special
  602.    organizations.  It is suggested that these organizations build a
  603.    subtree for information on AS which they are responsible for.
  604.  
  605. 4.3 Namespace objects
  606.  
  607.    The new IP namespace objects build a single tree in the Directory. It
  608.    is suggested that this tree will have a root of type
  609.    organizationalUnit within @o=Internet@ou=Network Information.
  610.  
  611.      objectClass= organizationalUnit
  612.      organizationalUnitName= IP networks
  613.      description= root of IP number tree
  614.  
  615.  
  616.  
  617.  
  618. Johannsen, Mansfield, Kosters & Sataluri                       [Page 11]
  619.  
  620. RFC 1608         IP Information in the X.500 Directory        March 1994
  621.  
  622.  
  623.    The tree is built under an administrative and an implementational
  624.    view.  Nowadays, network numbers usually are assigned to
  625.    organizations by (national) Network Information Centers (NIC) which
  626.    themselves have got a block of IP network numbers assigned from
  627.    another authority (e.g., IR at top level). This concept of delegated
  628.    blocks falling apart in smaller delegated blocks and IP network
  629.    numbers is used to model the Directory tree. Thus, an ipGroup object
  630.    is always subordinate of a delegated block object (namely the
  631.    delegated block including this IP number). Network numbers that were
  632.    directly assigned by a top-level authority, i.e., have not been
  633.    object of a delegation to a local assigning authority, will all be at
  634.    one level in the Directory.  Already today, however, we find many
  635.    delegations within the traditional class A-, B- and C-addresses.
  636.    Such a delegation is represented by a delegated block object, having
  637.    the assigned IP network numbers as subordinates. Also, part of the
  638.    block can be further delegated to another authority, leading to
  639.    another delegated block object within the parent delegated block's
  640.    tree.  Usually, subordinates of ipGroup objects are ipReferences,
  641.    i.e., single IP addresses as assigned to nodes. To support
  642.    subnetworking, it is also allowed to divide ipGroups into several
  643.    subnetwork ipGroups, each representing an IP subnetwork.  In such
  644.    cases, subnetwork numbers are given as subordinates to the assigned
  645.    IP network number.  Network masks clarify what the subnetwork
  646.    addresses are.
  647.  
  648.                          ou=IP networks
  649.                                |
  650.            +-------------------+-----------------------+
  651.           /                    |                        \
  652.                   dbl=150.0.0.0-150.100.0.0
  653.                                |
  654.            +-------------------+-----------------------+
  655.           /                    |                        \
  656.                          ipG=150.80.0.0
  657.                                |
  658.            +-------------------+-----------------------+
  659.           /                    |                        \
  660.                          ipG=150.80.240.0
  661.                                |
  662.            +-------------------+-----------------------+
  663.           /                    |                        \
  664.    ipRef=150.80.254.1    ipRef=150.80.254.2      ipRef=150.80.254.3
  665.  
  666.       Figure 2: Example population of IP namespace tree according
  667.                 to delegation and subnetworking.
  668.  
  669.    For some applications, the separation of ipImage (description of the
  670.    network) and ipGroup (description of the namespace element) will bear
  671.  
  672.  
  673.  
  674. Johannsen, Mansfield, Kosters & Sataluri                       [Page 12]
  675.  
  676. RFC 1608         IP Information in the X.500 Directory        March 1994
  677.  
  678.  
  679.    disadvantages in the look-up procedure. In that case one might think
  680.    of combining both object classes with the aim to provide one object
  681.    describing administrative and technical data for an IP network.
  682.  
  683.    As Autonomous Systems are an additional namespace to the existing IP
  684.    number space, they should go into a separate subtree. It is suggested
  685.    that this is an organizationalUnit within @o=Internet@ou=Network
  686.    Information.
  687.  
  688.      objectClass= organizationalUnit
  689.      organizationalUnitName= AS numbers
  690.      description= root of Autonomous System number space
  691.  
  692.    Similar to blocks of IP network numbers, blocks of AS numbers are
  693.    sometimes delegated to another registry. This is expressed by asBlock
  694.    objects.  These objects come below the root of the AS number space.
  695.    All AS numbers falling into such a block are stored as subordinates
  696.    of the block. An AS block may have smaller AS blocks underneath if
  697.    delegation is extended.
  698.  
  699. 4.4 Relationship to organizational entries
  700.  
  701.    Organizational information (i.e., white-pages-like information about
  702.    an organization, its departments and employees) occurs at several
  703.    places in the network DIT - [org of IP-Number, org of AS-Number, org
  704.    of Admin- contact, However, it will be basically mastered
  705.    [administered, maintained] by the organization itself in the
  706.    Directory Management Domain (DMD) over which the organization has the
  707.    authority.  This gives rise to some tricky problems - a typical
  708.    example is that of a NIC which holds the AS, DNS, IP, ...  subtrees
  709.    of the DIT.
  710.  
  711.    A good strategy would avoid explicit duplication of information.  By
  712.    explicit duplication of information we understand information being
  713.    duplicated outside the directory framework, e.g., by having several
  714.    master entries for one and the same piece of information. The only
  715.    way to avoid duplication would be to have relevant entries point to
  716.    the pertinent organizational entry for organizational information.
  717.    But since
  718.  
  719.      o most organizations do not, as yet, have an entry in the DIT and
  720.      o the reliability of the access to an organizations DIT when
  721.        stored in a remote DSA cannot be taken for granted,
  722.  
  723.    the following framework is adopted to accommodate the conflicting
  724.    requirements /conditions.
  725.  
  726.  
  727.  
  728.  
  729.  
  730. Johannsen, Mansfield, Kosters & Sataluri                       [Page 13]
  731.  
  732. RFC 1608         IP Information in the X.500 Directory        March 1994
  733.  
  734.  
  735.      o A copy of all the necessary organization-info is retained
  736.        at the NICs DSA. Since only  the  necessary info will be kept
  737.        the NIC will not be burdened to act as the repository of the
  738.        organizations DIT. These objects may be kept in a separate
  739.        subtree of affiliated-organizations [organizations
  740.        affiliated to the NIC]. Though the affiliated organizations node
  741.        does not really represent a locality, it is suggested to define
  742.        the node as objectClass locality. This does not break the
  743.        Directory schema when entries of organizations shall become
  744.        subordinate to the NICs organization's entry.
  745.  
  746.      o The problem of information duplication/consistency will arise when
  747.        organizational DITs/DSAs do come into existence. At that stage a
  748.        shadowing mechanism which will attempt to maintain the data
  749.        consistency may be resorted to. The X.500/ISO 9594(1993)
  750.        implementations are expected to provide appropriate shadowing
  751.        mechanisms along X.525.
  752.  
  753.    It may be noted that what is suggested is not a duplication of an
  754.    entire white-pages-like structure at the NIC.  It suggests an
  755.    "affiliated organizations node". The entries under this node will be
  756.    organization objects with a limited number of attributes, i.e., the
  757.    attributes to hold the organization info necessary for the NIC:
  758.    nothing more, nothing less.  Operationally, and content wise the NIC
  759.    DSA will hold exactly the amount of info that is desired by the NIC.
  760.    When an organization sets up its DSA and when the organization
  761.    informs the NIC about it, the NIC will set up the shadowing
  762.    arrangement to obtain info on changes of interest [and forget about
  763.    it].
  764.  
  765.    It may be emphasized that the entries under affiliated organizations
  766.    are physical entities [replicated and refined from the Master
  767.    entries, if and when they exist...] rather than alias entries. If a
  768.    NIC dislikes the idea of users poring over the entries in the
  769.    affiliated organizations - appropriate access control can be applied.
  770.    Though duplication is unavoidable, the proposal attempts to make it
  771.    transparent, by delegating the responsibility of maintaining the
  772.    integrity to the Directory.
  773.  
  774.    This issue is discussed in greater detail in a separate document [7].
  775.  
  776. 5. Security Considerations
  777.  
  778.    Security issues are not discussed in this memo.
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Johannsen, Mansfield, Kosters & Sataluri                       [Page 14]
  787.  
  788. RFC 1608         IP Information in the X.500 Directory        March 1994
  789.  
  790.  
  791. 6. Authors' Addresses
  792.  
  793.    Thomas Johannsen
  794.    Dresden University of Technology
  795.    Institute of Communication Technology
  796.    D-01062 Dresden, GERMANY
  797.  
  798.    Phone: +49 351 463-4621
  799.    EMail: Thomas.Johannsen@ifn.et.tu-dresden.de
  800.  
  801.  
  802.    Glenn Mansfield
  803.    AIC Systems Laboratory
  804.    6-6-3 Minami Yoshinari, Aoba-ku
  805.    Sendai 989-32, JAPAN
  806.  
  807.    Phone: +81 22 279-3310
  808.    EMail: glenn@aic.co.jp
  809.  
  810.  
  811.    Mark Kosters
  812.    Network Solutions, Inc.
  813.    505 Huntmar Park Dr.
  814.    Herndon, VA 22070
  815.  
  816.    Phone: +1 703 742-4795
  817.    EMail: markk@internic.net
  818.  
  819.  
  820.    Srinivas R. Sataluri
  821.    AT&T Bell Laboratories
  822.    Room 1C-429, 101 Crawfords Corner Road
  823.    Holmdel, NJ 07733-3030
  824.  
  825.    Phone: +1 908 949-7782
  826.    EMail: sri@qsun.att.com
  827.  
  828.  
  829.  
  830.  
  831.  
  832.  
  833.  
  834.  
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Johannsen, Mansfield, Kosters & Sataluri                       [Page 15]
  843.  
  844. RFC 1608         IP Information in the X.500 Directory        March 1994
  845.  
  846.  
  847. References
  848.  
  849.   [1]  Mansfield, G., Johannsen, T., and M. Knopper, "Charting Networks
  850.        in the X.500 Directory", RFC 1609, AIC Systems Laboratory,
  851.        Dresden University, Merit Networks,Inc., March 1994.
  852.  
  853.   [2]  Gerich, E., "Guidelines for Management of IP Address Space", RFC
  854.        1466, Merit, May 1993.
  855.  
  856.   [3]  Bates, T., Jouanigot, J.-M., Karrenberg, D., Lothberg, P., and M.
  857.        Terpstra, "Representation of IP Routing Policies in the RIPE
  858.        Database", Document ripe-81, RIPE, February 1993.
  859.  
  860.   [4]  Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting: An
  861.        Address Assignment and Aggregation Strategy", RFC 1338, BARRNet,
  862.        cisco, MERIT, OARnet, June 1992.
  863.  
  864.   [5]  Rose, M., and K. McCloghrie, "Structure and Identification of
  865.        Management Information for TCP/IP-based internets", STD 16, RFC
  866.        1155, Performance Systems International, Hughes LAN Systems, May
  867.        1990.
  868.  
  869.   [6]  Barker, P., and S. Kille, "The COSINE and Internet X.500 Schema",
  870.        RFC 1274, University College London, November 1991.
  871.  
  872.   [7]  Mansfield, G., Johannsen, T., and J. Murai, J., "Deployment
  873.        Strategy for the Directory in the Internet", AIC Systems
  874.        Laboratory, Dresden University, Keio University, Work in
  875.        Progress, July 1993.
  876.  
  877.  
  878.  
  879.  
  880.  
  881.  
  882.  
  883.  
  884.  
  885.  
  886.  
  887.  
  888.  
  889.  
  890.  
  891.  
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898. Johannsen, Mansfield, Kosters & Sataluri                       [Page 16]
  899.  
  900. RFC 1608         IP Information in the X.500 Directory        March 1994
  901.  
  902.  
  903. Appendix: OID tables
  904.  
  905.    This appendix lists object identifiers for object classes and
  906.    attributes type defined in [1] and this document.
  907.  
  908.    OIDs are given in quipu-oidtable format to make it easy for people to
  909.    include them into their pilots.
  910.  
  911.    IMPORT from oidtable.gen:
  912.  
  913.    iso:                            1
  914.    identifiedOrganization:         iso.3
  915.    dod:                            identifiedOrganization.6
  916.    internet:                       dod.1
  917.    experimental:                   internet.3
  918.    network-objects:                experimental.53
  919.  
  920.  
  921.    -- localoidtable.gen
  922.  
  923.    id-nw-oc:                       network-objects.1
  924.    id-nw-at:                       network-objects.2
  925.    id-nw-as:                       network-objects.3
  926.    ipStringSyntax:                 ip-nw-as.1
  927.  
  928.  
  929.    -- localoidtable.oc
  930.  
  931.    # general class definitions
  932.    # Format is -
  933.    #               Object: OID: SubClassOf: MustHave: MayHave
  934.  
  935.    CommunicationObject: id-nw-oc.1 : top : \
  936.             : \
  937.             adminContact, technContact, description
  938.  
  939.    PhysicalCommunicationObject: id-nw-oc.2 : CommunicationObject : \
  940.            : \
  941.            owner, localityName, ICO
  942.  
  943.    ImageCommunicationObject: id-nw-oc.3 : CommunicationObject : \
  944.            : \
  945.            imageType, imageOf
  946.  
  947.    # physical communication elements
  948.  
  949.    network: id-nw-oc.4 : PhysicalCommunicationObject : \
  950.            networkName : \
  951.  
  952.  
  953.  
  954. Johannsen, Mansfield, Kosters & Sataluri                       [Page 17]
  955.  
  956. RFC 1608         IP Information in the X.500 Directory        March 1994
  957.  
  958.  
  959.            externalGateway, nwType, media, speed, traffic, \
  960.            configurationDate, configurationHistory
  961.  
  962.    node: id-nw-oc.5 : PhysicalCommunicationObject : \
  963.            nodeName : \
  964.            typeOfMachine, OS
  965.  
  966.    networkInterface: id-nw-oc.6 : PhysicalCommunicationObject : \
  967.            networkInterfaceName : \
  968.            networkInterfaceAddress, connectedNetwork
  969.  
  970.    # image communication elements
  971.  
  972.    networkImage: id-nw-oc.7 : ImageCommunicationObject : \
  973.            : \
  974.            externalGateway, speed, traffic, charge
  975.  
  976.    nodeImage: id-nw-oc.8 : ImageCommunicationObject : \
  977.            :
  978.  
  979.    networkInterfaceImage: id-nw-oc.9 : ImageCommunicationObject : \
  980.            : \
  981.            networkInterfaceAddress, connectedNetwork
  982.  
  983.    # IP image elements
  984.  
  985.    ipNetworkImage: id-nw-oc.10 : networkImage : \
  986.            ipNetworkImageName, ipNwNumber, ipNwMask : \
  987.            associatedDomain, inAddrServer, asNumber, \
  988.            provider, onlineDate
  989.  
  990.    ipNodeImage: id-nw-oc.11 : nodeImage : \
  991.            ipNodeName : \
  992.            protocol, domainName
  993.  
  994.    ipNetworkInterfaceImage: id-nw-oc.12 : networkInterfaceImage : \
  995.            ipNetworkInterfaceName : \
  996.            ipNwMask
  997.  
  998.    as: id-nw-oc.13 : ImageCommunicationObject : \
  999.            asNumber : \
  1000.            asName, asIn, asOut, asDefault, asGuardian, \
  1001.            lastModifiedDate
  1002.  
  1003.    # number assignement objects
  1004.  
  1005.    assignedNumberClass: id-nw-oc.14 : top : \
  1006.            : \
  1007.  
  1008.  
  1009.  
  1010. Johannsen, Mansfield, Kosters & Sataluri                       [Page 18]
  1011.  
  1012. RFC 1608         IP Information in the X.500 Directory        March 1994
  1013.  
  1014.  
  1015.            assBy, assTo, assDate, nicHandle, relNwElement, \
  1016.            description
  1017.  
  1018.    delegatedBlock: id-nw-oc.15 : AssignedNumberClass : \
  1019.            delegatedBlockName, lowerBound, upperBound :
  1020.  
  1021.    ipGroup: id-nw-oc.16 : AssignedNumberClass : \
  1022.            ipGroupName, ipNwMask :
  1023.  
  1024.    ipReference: id-nw-oc.17 : AssignedNumberClass : \
  1025.            ipReferenceName :
  1026.  
  1027.    asBlock: id-nw-oc.18 : AssignedNumberClass : \
  1028.            asBlockName, asLowerBound, asUpperBound :
  1029.  
  1030.    asReference: id-nw-oc.19 : AssignedNumberClass : \
  1031.            asNumber :
  1032.  
  1033.  
  1034.  
  1035.    -- localoidtable.at
  1036.  
  1037.    adminContact:                id-nw-at.1     :DN
  1038.    technContact:                id-nw-at.2     :DN
  1039.    ICO:                         id-nw-at.3     :DN
  1040.    imageType:                   id-nw-at.4     :caseIgnoreString
  1041.    imageOf:                     id-nw-at.5     :DN
  1042.    networkName,nw:              id-nw-at.6     :caseIgnoreString
  1043.    externalGateway:             id-nw-at.7     :DN
  1044.    nwType:                      id-nw-at.8     :caseIgnoreString
  1045.    media:                       id-nw-at.9     :caseIgnoreString
  1046.    speed:                       id-nw-at.10    :numericString
  1047.    traffic:                     id-nw-at.11    :numericString
  1048.    configurationDate:           id-nw-at.12    :utcTime
  1049.    configurationHistory:        id-nw-at.13    :caseIgnoreString
  1050.    nodeName,nd:                 id-nw-at.14    :caseIgnoreString
  1051.    typeOfMachine:               id-nw-at.15    :caseIgnoreString
  1052.    OS:                          id-nw-at.16    :caseIgnoreString
  1053.    networkInterfaceName,ni:     id-nw-at.17    :caseIgnoreString
  1054.    networkInterfaceAddress:     id-nw-at.18    :caseIgnoreString
  1055.    connectedNetwork:            id-nw-at.19    :DN
  1056.    charge:                      id-nw-at.20    :numericString
  1057.    ipNetworkImageName,IPnw:     id-nw-at.21    :caseIgnoreString
  1058.    ipNwNumber:                  id-nw-at.22    :caseIgnoreString
  1059.    ipNwMask:                    id-nw-at.23    :caseIgnoreString
  1060.    inAddrServer:                id-nw-at.24    :DN
  1061.    asNumber,asN:                id-nw-at.25    :integerString
  1062.    provider:                    id-nw-at.26    :DN
  1063.  
  1064.  
  1065.  
  1066. Johannsen, Mansfield, Kosters & Sataluri                       [Page 19]
  1067.  
  1068. RFC 1608         IP Information in the X.500 Directory        March 1994
  1069.  
  1070.  
  1071.    onlineDate:                  id-nw-at.27    :utcTime
  1072.    ipNodeName,IPnd:             id-nw-at.28    :caseIgnoreString
  1073.    protocol:                    id-nw-at.29    :caseIgnoreString
  1074.    domainName:                  id-nw-at.30    :caseIgnoreString
  1075.    ipNetworkInterfaceName,IPni: id-nw-at.31    :caseIgnoreString
  1076.    asName:                      id-nw-at.32    :caseIgnoreString
  1077.    asIn:                        id-nw-at.33    :caseIgnoreString
  1078.    asOut:                       id-nw-at.34    :caseIgnoreString
  1079.    asDefault:                   id-nw-at.35    :caseIgnoreString
  1080.    asGuardian:                  id-nw-at.36    :DN
  1081.    assBy:                       id-nw-at.37    :DN
  1082.    assTo:                       id-nw-at.38    :DN
  1083.    assDate:                     id-nw-at.39    :utcTime
  1084.    nicHandle:                   id-nw-at.40    :caseIgnoreString
  1085.    relNwElement:                id-nw-at.41    :DN
  1086.    delegatedBlockName,dbl:      id-nw-at.42    :caseIgnoreString
  1087.    lowerBound:                  id-nw-at.43    :caseIgnoreString
  1088.    upperBound:                  id-nw-at.44    :caseIgnoreString
  1089.    ipGroupName,IPgr:            id-nw-at.45    :caseIgnoreString
  1090.    ipReferenceName,IPref:       id-nw-at.46    :caseIgnoreString
  1091.    asBlockName,asBl:            id-nw-at.47    :caseIgnoreString
  1092.    asLowerBound:                id-nw-at.48    :integerString
  1093.    asUpperBound:                id-nw-at.49    :integerString
  1094.  
  1095.  
  1096.  
  1097.  
  1098.  
  1099.  
  1100.  
  1101.  
  1102.  
  1103.  
  1104.  
  1105.  
  1106.  
  1107.  
  1108.  
  1109.  
  1110.  
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122. Johannsen, Mansfield, Kosters & Sataluri                       [Page 20]
  1123.  
  1124.